Skip to content

fix: Use POST instead of GET for multi-file downloads - #56543

Open
nfebe wants to merge 3 commits into
masterfrom
fix/7935/download-uri-too-long
Open

nfebe wants to merge 3 commits into
masterfrom
fix/7935/download-uri-too-long

Conversation

@nfebe

@nfebe nfebe commented Nov 19, 2025

Copy link
Copy Markdown
Contributor

When downloading multiple files as a ZIP archive, filenames were appended to the URL as query parameters, causing "414 Request-URI Too Long" errors with many files.

Backend now supports POST requests with files in request body. Frontend sends files via FormData in POST body instead of URL params.

Fixes #7935

@CarlSchwan
CarlSchwan force-pushed the fix/7935/download-uri-too-long branch from 87e9ed2 to 67f9615 Compare October 8, 2026 15:53
@CarlSchwan
CarlSchwan marked this pull request as ready for review October 8, 2026 15:54
@CarlSchwan
CarlSchwan requested review from a team and skjnldsv as code owners October 8, 2026 15:54
@CarlSchwan
CarlSchwan requested review from Altahrim, kristian-zendato, leftybournes, pringelmann, provokateurin and salmart-dev and removed request for a team October 8, 2026 15:54
@CarlSchwan CarlSchwan added 3. to review Waiting for reviews and removed AI assisted labels Oct 8, 2026
@CarlSchwan CarlSchwan self-assigned this Oct 8, 2026
// Send the file list in the request body to avoid too long URLs.
// A native form submission lets the browser stream the archive to disk.
const form = document.createElement('form')
form.method = 'POST'

@pringelmann pringelmann Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally: zipping a folder that contains a view-only share returns a 403 here. With a form submit, wouldn't the browser end up on that error page instead of staying in Files?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit tricky, I will try to figure out a solution

Comment thread apps/files/src/actions/downloadAction.ts
Comment thread apps/dav/lib/Connector/Sabre/ZipFolderPlugin.php
nfebe and others added 3 commits October 14, 2026 11:47
When downloading multiple files as a ZIP archive, filenames were
appended to the URL as query parameters, causing "414 Request-URI
Too Long" errors with many files.

Backend now supports POST requests with files in request body.
Frontend sends files via FormData in POST body instead of URL params.

Fixes #7935

Signed-off-by: nfebe <fenn25.fn@gmail.com>
Downloading the archive through axios as a blob buffered the whole
archive in memory and then failed, as HEAD requests on blob URLs are
not allowed. Submit a hidden form instead so the browser streams the
download natively.

Also reject non-string `files` parameters instead of failing with a
TypeError.

Assisted-by: ClaudeCode:claude-opus-5-5
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
@hirokawaguchi

Copy link
Copy Markdown

We hit this on a production Nextcloud 35.0.1 (Apache 2.4.58, PHP-FPM through mod_proxy_fcgi, HTTP/1.1). Selecting files with long Japanese names failed at about 20 files. The Files app reported "The requested files are not available." The request never reached the app: a probe of ?accept=zip&files= returned 401 at 8000 bytes and 414 at 8500, which matches Apache's default LimitRequestLine of 8190.

Raising LimitRequestLine is not enough on this stack. A query of about 20KB got past Apache and then failed with 500. The error log was AH02536: couldn't encode envvar 'QUERY_STRING' in 16384 bytes from mod_proxy_fcgi. One FastCGI PARAMS record cannot hold a single environment variable larger than 16KB, so the file list has to leave the query string.

The hidden form POST in this PR is the approach that worked for us. On 35.0.1 we taught ZipFolderPlugin to read files from an application/x-www-form-urlencoded body when ?accept=zip is set, and changed the multi-file action to submit that form instead of putting the JSON in the URL (a HEAD of the short folder URL, then POST). A body of 400 Japanese filenames, 28006 bytes, came back as 401 NotAuthenticated from Sabre rather than 414 or 500, so the size limit was no longer in the way. A normal form submit also keeps the browser's download dialog, which the earlier blob/XHR attempt could not.

We still carry that as a local patch because this host stays on 35.0.1. Happy to retest once this lands.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3. to review Waiting for reviews AI assisted

Projects

None yet

Development

Successfully merging this pull request may close these issues.

zip downloads: 414 Request-URI Too Long at download in web-interface

5 participants